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ABSTRACT 


Currently        the  Indonesian        Navy  Computer        Center 

(Dispullahtal)  has  a  need  for  a  Personnel  Data  Base  System 
which  satisfies  all  of  the  required  applications.  By  ana- 
lyzing the  aspects  of  the  personnel  management  in  the  Navy 
and  the  functions  required  to  implement  the  management  poli- 
cies, the  author  has  determined  the  data  elements*  relation- 
ships. Further,  from  the  data  elements'  relationships  and 
using  logical  Data  3ase  model  design  methods,  the  author  has 
derived  a  Personnel  Data  3ase  model.  Topics  discussed 
include:  transformations  of  data  elements  between  their 
logical  views  and  physical  representation,  security,  Data 
Base  dictionary  structure  and  characteristics,  journalizing 
transactions  to  facilitate  Data  3ase  recovery,  and  Data  Base 
administration.  The    author's      efforts      indicate  that      the 

Personnel  Data  3ase  presented  herein  is  worthwile  and  should 
be  implemented.  This  involves  the  organization  and  formation 
of  a  Data  3ase  Administration,  and  continuation  and  comple- 
tion   of    the    design. 
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I.     INTRODUCTION 


Since    1977   Dispullahtal    (Indonesian   Navy   Computer   Center) 
has    ncrked   at   developing   a    Personnel    Data   System    (PDS)       with 
emphasis    on   collecting      data,      and  then    processing      and   pre- 
senting   information1      to    users       (especially    the      top    manage- 
ment)   as    it    is   needed   to    facilitate    decision-making. 

The  data  which  has  been  collected  by  Dispullahtal  using 
PDS  for  each  person  employed  by  the  Department  of  Navy,  both 
military  and  civilian,  comes  primarily  from  Janminpersal 
(Department  of  the  Navy  Personnel  Administration)  as  well  as 
other  departments  involved  with  personnel  administration  and 
treatment.  After  its  collection,  the  data  is  stored  in  files 
which  are  related  to  the  various  applications  in  the  PDS. 
Currently  the  PDS  only  includes  the  functions  of  data  sto- 
rage and  information  retrieval.  Since  1977  Dispullahtal  has 
succeeded  in  convincing  the  system's  users  that  their  needs 
can  re  served  and  that  new  is  the  time  to  expand  the  PDS. 
The  period  for  this  expansion  has  been  designated  as  "Data 
Mechanization."  The  users  have  come  to  realize  that  they 
depend  on  Dispullahtal  for  the  processing  of  data  and 
reporting  of  information  which  is  timely  and  accurate.  Prior 
to  1S79,  the  system  was  not  able  to  provide  these  services 
in    the      manner    required      because    of      the    lack      of    up-to-date 


ifithin  the  context  of  this  thesis,  Data  and  Information 
are  leant  to  have  two  distinct  meanings.  Data  raters  to 
facts  collected  from  observations  or  measurements,  or  refers 
to  the  values  Dhysicaily  recorded  in  the  file  or  Data  Base. 
Inforaation  refers  to  the  meaning  assigned  to  those  fact  and 
values  as  a  result  of  interpretation,  correlation,  etc.  of 
data.  Data  is  Drocessed  into  information  so  that  it  can  be 
understood   and   employed    by    users.    [Ref.    3] 
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Inf ormatior.  in  the  system's  files.  Seeing  this  problem,  the 
Navy  conducted  a  census  of  its  personnel  in  1979  and  this 
data   is    currently   being    integrated  into   the   system. 

According  to  the  current  user  requirements,  Dispullahtal 
should  be  able  to  respond  immediately,  and  at  any  time,  with 
information  such  as  historical  data  (e.  g  historical  rank, 
education,  profession  etc.)  on  any  individual.  For  these 
requirements  Dispullahtal  has  started  organizing  all  the 
data  into  a  Data  3ase  System.  This  leads  to  the  next  phase 
of    Dispullahtal 's   planning    which    is   "Automation." 

Data  Base  Systems  are  needed  for  accomplishing  the 
requirements  and  demands  because  information  is  only  of 
value  so  long  as  it  supports  the  decision- making  process  and 
results  in  better  decisions.  To  be  useful  for  decision- 
making, information  must  be  current.  For  the  information  to 
be  current,  the  data  on  which  it  is  based  must  also  be  cur- 
rent. Current,  accurate  information  is  essential  for  the 
effective  operation  of  an  organization.  Therefore,  it  is 
necessary  to  have  a  means  of  collecting,  organizing,  stor- 
ing, and  correlating  the  data  and  to  be  able  to  extract  and 
distribute   the   information   as   it    is  needed. 

C.    J.    Date   [Ref.    3]    defines    a    Data    Base    system   as 

a  ccmcuter-based  recordkeep ina  system;  that  is,  a 
system  whose  overall  purpose  is  to  record  and 
maintain  information.  The  information  concerned 
can  be  anything  that  is  deemed  to  be  of  signifi- 
cance tc  the  organization  the  system  is  servina- 
anything,  in  other  words,  that  may  be  necessary  to 
the  decision- making  processes  involved  in  the  man- 
agement   cf    that    organization.    ... 

Data  Ease  system  involves  four  major  components: 
data,    hardware,    software   and   users. 

Date    further    defines    a    Data   Base   as 

a  collection  of  stored  operational-data2  used  by 
the  application  systems  of  some  particular 
ent  er prise. 3 


iperational-data   would   probably    include:      product    d 
it   data,    patient   data,    student  data,    planning  data. 


A  Data  Ease  system  provides  the  enterprise  with  central- 
ized control  of  its  operational  data.  Some  of  the  advantages 
that  accrue  from  this  centralized  control  are: 

-  Redundancy  can  te  reduced, 

-  Inconsistency  can  be  avoided, 

-  Data  can  be  shared, 

-  Standards  can  be  enforced, 

-  Security  restrictions  can  be  applied, 

-  Integrity  can  be  maintained ,  and 

-  Conflicting  requirements  can  be  balanced. 

Eased  en  these  above  mentioned  advantages,  personal 
experience  in  processing  personnel  data  prior  to  coming  to 
the  Naval  Postgraduate  School,  and  information  gained  from 
courses  taken  recently  at  this  school,  this  author  is 
attempting  to  design  "The  Eleaentary  Personnel  Data  Base 
System  for  the  Indonesian  Navy".  This  Data  Base  System  is 
propesed  in  order  to  fulfill  some  of  the  requirements  of  the 
Management  Information  System  (MIS)  in  the  Navy  as  posted  in 
the  "System  Informasi  Pembinaan  TNI-AL"  (Navy  MIS). 

Tc  accomplish  this  goal,  the  author  obtained  information 
concerning  user  requirements  from  Dispull ahtal.  The  three 
sections  of  'his  thesis  are: 

1.   User  requirements  definitions  which   analyze  the  user 
requirements  and  data  elements. 


Enterprise  is  simDly  a  convenient,  generic  term  for  anv 
reasonably  self- contained  commercial,  scientific,  technical^ 
or  ether  type  of  organization.  Some  examples  are: 
Manufacturing  Company,  Bank,  Hospital,  University, 
Government  Deoartment. 


2.  Data   Ease    design      which   considers   the    data      model    and 
special   discussions    for   further    implementation. 

3.  Conclusions   and   recommendations. 

At  the  ecd  are  appendices  which  contain  the  List  of  data 
elements  from  file  system,  Data.  Ease  Dictionary,  and  Data 
Base  personnel  tables. 

Kelvin  B.  Klein  and  Helvin  W.  Lifson  [Ref.  9]  in  their 
lecture  notes  regarding  Systems  Engineering  says  tha' 


5xceu._cns,  ~ne  svsxem  mus-  ds  ao 
tinuing  ana  changing  need  over  a 
of  time  in  order  to  justify  t 
time,  money,  and  effort. 


specified  period 
he  investment   in 


It  is  the  author's  believed  that  the  proposed  system  will 
be  able  to  be  easily  improved  according  to  the  technological 
demands  of  the  future. 
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II.     USER    RJ0JJIRE3ENTS    DEFINITIONS    AND    ANALYSIS 

A.     GENERAL 

Wise  personnel  decisions  demand  data  about  the  individu- 
als upon  which  decisions  may  be  based,  the  special  require- 
aents  of  jobs,  and  interactions  between  these  two. 
Systematic  procedures  exist  for  gathering  this  data  about 
people,  jobs,  job  behavior;  and  for  estimating  their  inter- 
relationships.  This  should  lead  to  the  assurance  that 

the  right  oeople  move  into  the  right  jobs  at  the 
right  times  and  under  the  right  circumstances. 
[Ref.  5] 

Personnel  decision-making  is  a  never  ending  process, 
encompassing  not  only  individual  diagnosis  and  job  analysis, 
but  also  job  design,  career  guidance,  and  personnel  develop- 
ment and  training.  People  differ  greatly  from  one  another, 
but  this  fact  does  not  carry  implications  about  the  static 
or  dynamic  nature  of  .human  abilities,  needs,  motives,  and 
behavioral  tendencies.  In  fact,  the  pervasiveness  of  both 
the  inter-  and  intra-indiv idual  differences,  and  the  tempo- 
ral changes  in  human  qualities  are  precisely  why  psycholo- 
gists must  take  such  special  care  in  individual  diagnosis  as 
a  basis  for  making  sound  personnel  decisions.  Scientific 
evidence  about  the  individuality  of  people  should  supplant 
the  hunches,  arbitrary  judgments,  invalid  rules  of  thumb, 
and  aethods  of  trial  and  error  that  unfortunately  have  char- 
acterized so  many  programs  of  personnel  selection  and  job 
placement  in  the  past.  Learning  about  people  systematically 
and  scientifically  is  the  best  avenue  toward  wise  and  effec- 
tive utilization  of  our  human  resources. 
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Marvin    D.    Dunnette  [Ref.    5]  calls 

...personnel        selection  a        gigantic        casting 

process — a    process    m    which  auditions    occur   and   in 

which      human      behavicr      is  assessed.         wisely      or 
unwisely,      validly    or      invalidlv.      obviously,      the 

fairness   of   such   auditions  and* their    relevance   to 

per  romance   is  the   central  concern   of   the   person- 
nel   decision   maker. 

Ideally,  personnel  decision  making  extends  much  further 
to  include  the  possibilities  for  job  redesign,  counseling 
and  guidance;  the  removal  of  organizational  constraints;  and 
the  design  of  specialized  training  or  development  programs. 
Thus  mapping  the  individuality  of  persons  is  necessary  not 
only  for  personnel  selection  and  placement,  but  for  all 
other   personnel    programs   as  well. 

The  Indonesian  Navy  takes  in  hundreds  of  men  each  month; 
they  must  be  placed  into  an  extremely  broad  range  of  duty 
assignments,  training  programs,  and  schools.  Each  man 
inducted  must  be  utilized  somewhere  in  the  system.  The  prob- 
lem involves  very  detailed  classification,  and  it  is  desira- 
ble for  both  the  Navy  and  the  men  involved  to  ensure  that 
assignment  procedures  successfully  achieve  a  close  match 
between    human   skills    and    job   requirements. 


B.     ASPECTS    OF    NAVAL    PERSONNEL    MANAGEMENT 

The  Management,  of  the  Navy's  personnel  system  provides  a 
means  to  activate  the  system,  use  it  as  a  communication 
tool,  conform  to  the  social  changes,  and  coordinate  with  the 
other  sub-systems  in  the  Navy.  This  management  includes  two 
major  aspects,  each  with  several  subf unctions:  (1)  a  man- 
power building  aspect  which  includes  functions  involves 
planning  and  investigation,  and  (2)  a  personnel  administra- 
tion aspect  which  includes  functions  involving  procurement, 
education      and        training,        assignment,  treatment,         and 

separation. 
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1.    The    Banpower   Building  Aspect 

In  personnel  planning  it  must  be  determined  what  posi- 
tions must  be  filled  (what  professions  are  needed)  and  what 
skills  are  needed  to  accomplish  the  required  goals  of  the 
Navy's  organization.  Planning  must  take  place  on  how  to  fill 
these  positions  either  with  personnel  the  Navy  currently  has 
or  by  procuring  new  personnel.  To  accomplish  this  it  is 
necessary  to  carefully  investigate  or  examine  all  of  the 
relevant  factors,  internal  and  external,  which  influence  the 
validity  and  success  of  this  planning.  Internal  factors 
include  all  the  problems  which  relate  to  the  personnel  sys- 
tem itself,  while  external  factors  are  those  which  come  from 
outside  the  Navy  that  directly  and/or  indirectly  influence 
its    personnel   planning. 

2 •   £ers cnnel    Adainistration 

This  second  aspect  of  personnel  planning  includes  a 
number  of    sub-functions.    They   are: 

» 

a.    Personnel   Procurement 

Personnel  procurement  is  the  process  of  gaining 
■an p ewer  for  filling  vacant  positions  which  cannot  be  filled 
from  within  the  organization  itself.  Efficient  procurement 
oerscnnel  must  have  information  concerning  the  candidate's 
education,  qualifications,  experience,  skills,  etc.  After 
candidates  have  been  selected,  their  data  can  be  kept  and 
maintained  so  that  it  can  be  used  at  any  time  for  transfer, 
new    assignment,    promotions,    etc. 
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b.  Personnel   Education   and    Training 

Information  regarding  the  education  and  training  of 
personnel  is  used  mainly  for  personnel  development  and  pro- 
motion. This  information  is  used  to  match  or  minimize  the 
difference  between  skills  required  to  fill  a  position  and 
the  skills  pcssesed  by  those  who  will  occupy  the  position.  A 
person's  educational  background  can  be  used  to  gain  special 
knowledge  needed  placing  a  person  in  a  particular  job  and  to 
prepare  that   person      for   a    new  assignment.  Further,      this 

information  can  be  used  to  plan  and  monitor  the  careers  of 
leaders,  or  those  personnel  with  special  abilities  who  will 
be  future  leaders,  to  extend  their  abilities  and  skills  in 
preparation    for    future    positions. 

The  results  of  personnel  development  can  be  mea- 
sured by  observing  the  performance  of  individuals  in  gaining 
necessary  skills  and  abilities.  This  information  can  be 
recorded  in  the  personnel  data  and  used  as  a  basis  for 
further   career   development. 

c.  Personnel   Assignment 

Personnel  assignment  deals  primarily  with  selecting 
the  right  people  for  the  right  positions.  Two  aspects  must 
be  considered: 

(1)  Every  vacant  position  must  be  filled  by  a  per- 
son with  the  ability  to  carry  out  the  job  in  the  best  man- 
ner, and 

(2)  The  abilities  and  skills  of  each  person  must  be 
fitted  to  the  job  so  that  he  feels  satisfied  with  the  job 
area. 

In  order  to  accomplish  the  above,  it  is  necessary 
to  have  a  profile  of  the   skill/ability  of  each  position,   a 
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profile   of   the   skill/ability   of    each    person   concerned,    and   a 
periodic    evaluation   of   each  person. 

d.  Personnel  Treatment 

Personnel  treatment  deals  with  the  physical  aspects 
of  the  person  and  the  job.  These  include  such  things  as  men- 
tal and  physical  health,  physical  work  and  recreation, 
rewards,  and  personnel  services.  The  latter  benefits  include 
transportation,  salary,  retirement  plans  and  insurance, 
vacations  and  annual  and  sick  leave,  and  cooperation  between 
the  vicrker  and  the  employer. 

e.  Personnel  Separation 

Personnel  separation  occurs  whsn  the  person  volun- 
tarily asks  to  be  released  from  the  military  or  goes  through 
the  process  of  retirement.  Information  about  the  people  who 
are  terminating  must  be  completed  in  order  for  the  personnel 
management  system  to  give  leads  (directions)  to  other  oppor- 
tunities and  fields.  This  can  be  beneficial  to  both  the 
individual  and  to  the  system.  If  the  person  voluntarily 
leaves,  the  system  should  be  able  to  gain  valuable  insights 
into  ways  of  improving  the  Navy  so  as  to  reduce  the  number 
of  voluntary  separations. 

3  •  Conclusions 

It  can  be  clearly  seen  that  the  personnel  management 
system  must  have  a  great  deal  of  relevant  information  in 
order  to  proceed  efficiently  and  effectively  through  all  of 
the  aspects  involved.  This  supporting  information  must  be 
complete  and  it  must  be  up-to-date.  This  can  be  accom- 
plished  only  if   the  relevant  data   is   also  complete   and 
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up-to-date.  Moreover,  in  order  to  meet  the  needs  of  all  of 
the  functions,  management  must  also  keep  historical  data 
such  as  rank,  profession,  education,  etc. 

It  can  also  be  seen  that  one  function  may  need  the 
same  information  as  another  function.  For  example,  the  edu- 
cation and  training  function  needs  information  about  the 
educational  history  of  a  person  so  that  it  can  be  used  to 
fit/match  an  assignment  or  profession  to  that  person.  This 
same  information  would  again  be  used  at  the  time  of  separa- 
tion for  helping  the  person  into  a  new  position. 

If  each  function  were  separately  filed  and  managed, 
the  information  for  each  individual,  there  would  be  great 
duplication.  In  addition,  if  the  data  in  one  file  changed, 
the  data  in  the  ether  files  would  also  need  to  change;  this 
would  necessitate  a  great  deal  of  time  and  energy  in  updat- 
ing several  files  containing  the  same  information.  In  order 
to  prevent  this  duplication  of  files  and  to  save  time  and 
energy,  a  Personnel  Data  Base  is  needed.  This  would  be  a 
collection  of  data,  either  historical  or  otherwise,  which 
could  be  used  in  all  functions  of  personnel  management. 
Updating,  inserting,  and  deleting  of  information  could  be 
performed  only  once.  This  would  become  the  Personnel  Data 
Base. 

C.  TYPICAL  DS2B  REQ02ST  AND  APPLICATIONS 

Before  discussing  a  typical  Navy  user  information 
request,  it  is  necessary  to  define  what  the  user  is  in  this 
system.  According  to  C.J.  Date  [ Ref .  3]  there  are  three 
broad  classes  of  users: 

1.  The  application  programmer,  who  is  responsible  for 
writing  application  programs  which  use  the  Data  Base. 
These  application  programs  operate  on  the  data  in  all 


16 


the  usual  ways:  retrieving  information,  creating  new 
information,  and  deleting  or  changing  existing  infor- 
mation. The  programs  themselves  may  be  conventional 
batch  applications,  or  they  may  be  on-line  programs 
that  are  designed  to  support  an  end-user  interacting 
with   the    system   from  an  on-line   terminal. 

2.  The  end-user,  who  accesses  the  Data  Base  from  a  ter- 
minal. An  end-user  may  employ  a  query  language  pro- 
vided as  an  integral  part  of  the  system,  or  he  or  she 
a  ay  invoke  a  user- written  application  program  that 
accepts  commands  from  the  terminal  and  in  turn  issues 
requests  to  the  DBMS  on  the  end-user's  behalf.  Either 
way  the  user  may,  in  general,  perform  all  the  func- 
tions of  retrieval,  creation,  deletion  and  modifica- 
tion, although  it  is  probably  true  to  say  that 
retrieval  is  the  most  common  function  for  this  class 
of    user. 

3.  The   Data    Base    Administrator    (DBA),      who    is   the    person 

(or   grcup  of   persons)    responsible   for   overall   control 
of    the   Data    Base    system.     This    control    includes: 

a)  Deciding   the    information   content    of   the   Data    Base. 

b)  Deciding        the        storage      structure        and        access 
strategy. 

c)  Making    liaison   with   users, 

d)  Defining      authorization        checks      and        validation 
procedures. 

e)  Defining   a    strategy    for   backup   and    recovery. 

f)  Monitoring    performance      and   responding      to   changes 
in    requirements. 
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In  this  thesis  the  author  defines  the  user  according  to 
the  three  classes  mention  above  and  according  to  who  uses 
this    Data    Base. 

According  to  the  SIP-TNI-AL  (Navy  MIS)  [Ref.  10],  sys- 
tem's   users   include  the   following: 

1.  Headguarters   level: 

a)  Manager   level, 

b)  Staff    level, 

c)  Central  executive  level, 

d)  Support  level, 

e)  Field  technical  executive. 

2.  Station  level: 

a)  Manager  level, 

b)  Staff  level, 

c)  Executive    level:      i.e.,    command   executive,      opera- 
tional  group,    ship,    Marine. 

3.  Extra  Structural  level:  This  level  is  the  non- 
structured   organization. 

Based  on  the  two  major  aspects  of  personnel  system  man- 
agement and  their  breakdowns  into  functions,  some  examples 
cf    user   reguests   and   applications   might    include: 

1.  List  all  officers  with  rank  of  Colonel  who  have  edu- 
cation at  the  Staff  and  Command  College  level,  and 
have   held   command   of  a    frigate    ship. 

2.  List  each  Lieutenant  Colonel's  profession  from  Ensign 
through  current  profession,  and  their  educations 
either   military   or    general. 
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3.  Recapitulate  an  officer's  career  from  First 
Lieutenant   through   Colonel. 

4.  List    the    data    characteristics    of   a    person. 

5«  Present  an  information  list  for  rank  promotion  pur- 
poses, listing  the  matrix  value  calculation.  Include 
rank,    profession,    education,    and   security   clearance. 

6.  Process    the   automatic    monthly    payments. 

7,  Show  a  list  of  family  members  (spouse,  children, 
etc)  . 

The  output  forms  for  this  information  are  not  included  in 
this  thesis,  as  they  can  vary.  Also,  the  applications  of 
this  information  may  change  and  become  more  complicated 
according    to    the   user   requests. 


D.     DATA    ELEMENTS    AND    THEIR    GROUPINGS 

a  trend  toward  more  integrated  file  structures  has 
resulted  in  the  grouping  together  of  all  data  items  relevant 
to  the  management  and  operations  section  of  a  user  organiza- 
tion. The  emerging  Data  Ease  concept  requires  placing  all 
relevant  data  in  one  Data  Ease  in  a  consistent  and  standard- 
ized manner,  eliminating  unnecessary  duplication  and  file 
handling,  and  providing  selective  inquiry  and  extraction 
capabilities  designed  to  meet  a  wide  variety  of  information 
requests . 

In  orier  to  meet  the  requirements,  the  author  had  to 
extract  specific  data  elements  from  the  1979  Navy  census  and 
from    the       file   system   with      minor   modifications.  The   file 

system  as  it  is  currently  structured  contains  100  (one  hun- 
dred) separate  data  elements  which  can  be  extracted.  These 
data    elements   are    posted    in   Appendix    A. 
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After  making  analysis  of  them,  eliminating  some  redundant 
or  unnecessary  duplications  and  adding  some  data  elements 
which  are  needed  for  the  Data  Base  model,  the  author  has 
restructured  the  Data  Base  so  that  it  now  contains  only  97 
(ninety  seven)  data  elements  which  are  divided  into  two 
basic  groups: 

1.  Data  elements  that  are  almost  static  in  relation  to 
others.  These  elements  consist  of  data  that  will  not 
be  frequently  changed.  These  data  elements  are  also 
divided  into  two  smaller  groups: 

a)  Data  elements  which  will  frequently  be  used  or 
retrieved  by  applications  programs  would  be 
grouped  in  Hain  Identification,  This  group 
includes  eight  data  elements:  personnel  serial 
number,  name,  corps,  sex,  birth's  date,  religion 
and  tribe. 

b)  Data  elements  which  would  be  seldomly  retrieved  by 
applications  programs  are  grouped  in  Personnel 
Characteristics,  This  group  would  usually  be  used 
for  intelligence  purposes.  This  group  is  divided 
further  into  four  subgroups: 

i)  Harriage  subgroup  (this  group  may  be 
repeated)  which  contains  two  data  elements: 
marital  status,  and  date  of  marriage. 

ii)  Address  subgroup  (this  group  may  be 
repeated)  which  contains  three  data  ele- 
ments: address,  housing  status,  and  date  of 
housing  status. 

iii)  Body  characteristics  subgroup  (this  group 
will  occur  only  once)  which  contains  eleven 
data  elements:    weight,  height,  blood  type, 
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hair,  colour  of  skin,  colour  of  eyes,  size 
of  shoes,  size  of  hat,  size  of  pants,  size 
of   shirt,    and   size  of  chest. 

iv)  Category  and  status  subgroup  (this  group 
will  occur  only  once)  which  contains  seven 
data    elements:  original    personal      status, 

date  of  original  personal  status,  current 
personal  status,  date  of  current  personal 
status,  personal  category,  date  of  personal 
category,  and  active  duty  obligation  time 
(active    duty   service    began). 

Data  elements  that  are  dynamic,  frequently  changed, 
and  which  most  require  replication  for  historic  pur- 
poses. These  data  can  be  subdivided  into  several 
groups  according  to  their  corresponding  historical 
data    applications.    These    groups   include: 

a)  Rank  group  (this  group  is  repeated)  which  contains 
seven  data  elements:  rank,  rank  status,  date  of 
rank,  number  of  decision  letter,  date  of  decision 
letter,  who  gave  the  decision  letter,  and  type  of 
promotion. 

b)  Profession  group  (this  group  is  repeated)  which 
will  contains  ten  data  elements:  name  of  profes- 
sion, number  of  decision  letter,  date  of  profes- 
sion, number  of  professional  warrant,  date  of  war- 
rant, group  (echelon)  of  profession,  station, 
reporting  date  at  station,  status  of  placement, 
and   date  of    placement. 

c)  Education  group  (this  group  is  repeated)  which 
contains  nine  data  elements:  group  code  of  educa- 
tion, educational  institution's  name,  start  date, 
completion  date,  station,  town,  result  of  educa- 
tion,   class    standing,     and   class    size. 
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In  addition  this  group  contains  the  repeated 
subgroups;  i.e.  Subjects  (which  contains  two  data 
elements:    subject   name,    and   grade). 

d)  Faaily  group  (this  group  is  repeated)  which  con- 
tains seven  data  elements  of  each  family  and  mem- 
bers: family  name,  family  relation,  sex,  date  of 
birth,  place  of  birth,  religion,  and  address.  In 
addition  there  two  repeating  occurence  subgroups 
data   elements    for  each    family  and    members: 

i)  Activity   5      Profession   subgroup       (this    group 

is  repeated)  which  contains  four  data  ele- 
ments: name  of  activity,  place  of  activity, 
start   date,   and    completion    date. 

ii)         Education   subgroup    (this      group   is   repeated) 
which   contains   three      data    elements:      educa- 
tional     institution's   name,         group   code      of 
education,    and  result   of   education. 

e)  Payroll  group:  this  group  need  not  be  broken-down 
further  since  it  is  usually  only  for  the  monthly 
payroll  application,  which  contains  forteen  data 
elements:  date  of  beginning  payroll,  rank  in  pay- 
roll, payroll  period  (month) ,  number  of  children 
authorized  family  allowance,  status  of  children 
authorized  family  allowance,  main  salary,  wife's 
family  allowance,  children's  family  allowance, 
other  family  allowances,  obligated  reductions, 
rice  reductions,  other  reductions,  total  salary, 
and   unit   of    payroll. 

f)  Security  group  (this  group  is  repeated)  which  con- 
tains six  data  elements:  violation/infringe  type, 
what,  where,  when,  why,  and  how.  In  addition  there 
ars  two  subgroups  for  each  7iolation/Inf ringe 
type: 
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i)  Who  Involved  subgroup  (this  group  is 
repeated)  which  contains  three  data  ele- 
ments: name  involved,  personal  identifica- 
tion, and  profession. 

ii)  Measures  subgroup  (this  group  might  be 
repeated)  which  contains  three  data  ele- 
ments: action  type,  start  date,  and  comple- 
tion date. 

Data  elements  which  will  become  the  key  to  each  group  can 
be  found  in  the  next  chapter  (Data  3ase  Model  Design). 
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III.     DATA    BASS    HO  DEL    DESIGN 

A.     GENESAL 

Considering  the  foregoing  synopsis  of  user  requirements 
and  the  DBMS4  (Data  Base  Management  System) ,  a  number  of 
important    questions  are   raised.    Among   these   are: 

1.  What  are  appropriate  data  structures  with  which  to 
implement   the    physical    Data   Base   ? 

2.  What  are  the  properties  of  a  useful  data  model,  and 
how  should  they  be  represented  in  the  physical 
structures. 

In  this      chapter   the    author  will    examine   the      problem    of 

what    the    Data   Base   should    look  like    to    the    user;      i.e.,    what 

would   be      the   appropriate    data  model   to   implement      the   real 
world. 

A  model  is  a  basic  system  of  constructs  used  in  describ- 
ing reality.  It  reflects  a  person's  deepest  assumptions 
regarding  the  elementary  essence  of  things.  It  may  be  called 
a  world  view.  It  provides  the  building  blocks,  the  vocabu- 
lary that  pervades  all  of  a  person's  descriptions.  A  model 
is  mere  than  a  passive  medium  for  recording  our  view  of 
reality.       It   shapes  that   view,    and   limits   our   perceptions. 

The  organization  of  the  data  is  represented  by  a  data 
model.  A  data  model  is  an  intellectual  tool  used  to  under- 
stand the  logical  organization  of  data.  To  understand  data 
models  fully,  it  is  necessary  to  be  aware  of  how  people  per- 
ceive   data.    Data   can    be    discerned   at    several    levels.       At    one 


♦DBAS    is      the   software    which      handles    all    access      to    tne 
Data    5ase. 
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level,  people  logically  organize  their  perceptions  of  the 
real  world.  At  another  level,  they  interpret  (give  meaning 
to)  the  real  world.  Finally,  they  use  data  models  to 
describe  and  record  the  interpretation  of  the  world  as  data 
in    their    computers   or   perhaps    in    seme    other    physical    medium. 

A  data  model  must  be  rich  enough  in  structure  to  describe 
the  significant  aspects  of  the  real  world,  yet  it  must  be 
possible  to  determine  fairly  automatically  an  efficient 
implementation  of  the  conceptual  scheme  by  a  physical 
scheme.  The  conceptual  scheme  is  an  abstraction  of  the  real 
world   pertinent    to   an   enterprise. 

D.    C.    Tsichritzis    and    F.    H.    Lochovsky   [ Ref .       18]   define    a 

data   model   as 

a  pattern  according  to  which  data  are  logically 
organized.  It  consists  of  named  logical  units  of 
data  and  expresses  the  relationships  among  the 
data  as  determined  by  the  interoretation  of  a 
model    of   the    world. 

One  of  several  data  models  can  be  used  to  represent  the 
interpretation  of  a  model  of  the  world.  The  main  difference 
between  them  is  the  manner  in  which  they  represent  certain 
relationships   among    the    data. 

Data  values,  by  themselves,  say  nothing  meaningful.  Some 
information  will  be  available  if  a  relationship  has  been 
established    between   the    values. 

A  relationship  is  an  association  among  several  things, 
with  that  association  having  a  particular  significance. 
Relationship        might        be      one-to-one,  one-to-many ,  or 

man y-to- many . 

There  are  3  major  data  models  that  have  been  used  in  Data 
3ase    systems: 

1 ■  Relational:  this  model  is  based  on  the  set  theoretic 
notion  of  a  relation,  that  is,  a  set  of  k-tuples  for 
some    fixed    k. 
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2.  Hierarchical:  this  data  model  is  a  tree,  where  nodes 
might   represent:   data   elements   groups. 

3-  Network:  this  is  the  directed  graph  model,  where 
nodes  represent  sets  of  similar  entities  and  arcs 
represent   associations. 

Tc    see    the      roll   or   place   of      the    data   model    in      the  Data 

Base   System    as    viewed   by   users,       can    be   seen    in    Diagram  1    as 

a   general    architecture   for    a   Data   Base  System   extracted  from 
C.    J,    Date's    book   (Ref.    3]. 
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The  Data  Base  is  the  data  as  physically  recorded  (the 
storage  structure) .  In  between  the  Data  Base  and  the  users 
is  interposed  the  data  model,  which  is  the  information  con- 
tent cf  the  Data  Base  as  it  is  viewed  by  the  users;  that  is, 
to    the      users   the    data      model    is      the    Data    Base.  The    data 

model   definitions     define    the      various   types      of   data      model 
records,  s 

In  practice  most  users  will  be  interested  only  in  a  small 
portion  of  the  total  data  model.  The  facility  is  therefore 
provided  of  extracting  a  data  submodel  from  the  complete 
data  model  by  means  of  a  data  submodel  description.  A  data 
submodel  may  be  considered  as  the  restriction  of  the  total 
data  model,  to  just  that  portion  of  interest  to  a  particular 
group   of    users      (the   community   user   view).  It   consists    of 

multiple      occurrences   of      multiple      types      of    data      submodel 
record. 

Different  terms  are  used  to  describe  analogous  concepts 
in  different  Data  Base  architectures.  Table  1  lists  terms 
used  in  these  different  models  (the  general  model  described 
in  Diagram  1,  the  Data  3ase  Task  Group  model  (DBTG)  ,  and  the 
Information  Management  System  model  (IMS))  and  their  corre- 
lation. That  is,  the  concepts  of  data  model  and  data  submo- 
del correspond  respectively  to  schema  and  subshema6  in  DBTG, 
and  Data  3ase  Description  (D3D)  and  the  set  of  all  Program 
Communication  31ock  (PCB)  plus  the  associated  mapping  defi- 
nition called  Program   Specification   31ock    (?SB)  7    in   IMS. 


5A  record  is  a  named  collection  of  zero,  one,  or  more 
da*a    elements  or   data   aggregates. 

*Sche«a  is  the  complete  description  of  all  the  elements 
in  a  Data  Base.  It  includes  the  names  and  descriptions  of 
all  data  elements,  data  aggregates,  record  occurrences,  and 
areas  that  are  Dart  of  the  Data  Base.  While  Subschema  is  a 
consistent  and  'logical  subset  of  the  schema  from  which  it 
was    obtained   [Ref.    7    and   6]. 

72ach  physical  Data  Base  is  defined  by  a  DBD,  the  man- 
ning of  phvsical  Data  Base  to  storage  is  also  SDecified  (at 
least    in       part)       in      the   DBD.  Each    logical      Data   Base      is 
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Table  1_«  Comparison  of  terras  in  various 
Data  Base  Architectures 


Architecture 
General         DBTG  IMS 


Data  Model      Schema       set  of  all  DBD  (Data 

Base  Description) 

Data  Submodel   Subschema     set  of  all  PCB  (Program 

Communication  Block) 
plus  the  associated  map- 
ping definition  called 
PSB  (Proaram  Specifica- 
tion Block) 

Workspace       OWA  (User    I/O  (Input/Output)  area 

work   Area)  r  * 

Language  Host   Lang-        Host    Language    +    DL/I 

uage   +    DML         (Data    Language/I) 
j[Data    Man- 
ipulation 
Language) 

DBMS  DBMS  IMS    Control    Program 


B.     APPLICATIONS    TO    DATA    ELEMENTS     GBOOPS    MAPPING    ANALISIS 

The  decision  to  implement  a  Data  Base  is  motivated  by  the 
need  to  share  data  among  a  variety  of  diverse  applications 
and  to  integrate  data  for  supporting  more  sophisticated 
applications.  3oth  of  these  reguireraents  complicate  the 
already  difficult  task  of  providing  safe  and  efficient 
access  to  computerized  data*  DBMS's  have  evolved  to  answer 
two  critical  needs:  support  for  more  interrelated  data  and 
suppcrt  for  sharing  data  among  many  diverse  applications. 
These  goals  are  being  achieved,  in  part,  by  providing  DBMS 
software      to      physically      link      related      data      into      complex 


defined.  together  with  its  mapping  to  the  corresponding 
phvsicai  Data  Base,  by  means  of  PCB.  Each  user  has  its  own 
PS3  (that  is,  ?S3s  may  not  be  shared,  though  two  distinct 
?S3s    mav    actually   contain   the    same   information).    [ Ref .    3  1 
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structures  using  such  mechanisms  as  pointer  chains,  indices, 
and  sequential  positioning.  They  are  also  being  achieved  by 
the  development  of  Data  Base  design  methodologies  and  rules 
such  as  the  practice  of  storing  information  in  a 
non-redundant  fashion  so  that  changes  by  one  application  to 
the  single  copy  of  the  data  are  seen  by  ail  its  users.  In 
other  words,  that  it  is  expected  that  the  updates  of  each 
user  will  be  apparent  to  the  other  users  of  the  data  because 
a    major   goal    of    Data    Base    Management    is  data    sharing. 

Table  2  shows  the  mapping  of  applications  to  the  data 
elements  groups  from  the  previous  chapter  (User  Requirements 
Definitions  and  Analysis)  as  the  external  views8  which 
serves  as    a   basis   for   designing    a   data   model. 

In  the  table,  the  following  abbreviations  are  used: 
HUMID  for  Main  Identification,  PBRSCHAR  for  Personal 
Characteristics,  MARR  for  Marriage,  ADDR  for  Address, 
BODYCHAR  for  Body  Characteristics,  CATE3  for  Category  and 
Status,  RANK  for  Rank,  PROFF  for  Profession,  EDUC  for 
Education,  SDBJ  for  Subjects,  FAM  for  Family,  FACT  for 
Families's  Activity,  FEDUC  for  Families's  Education,  PAYROLL 
for  Payroll,  SEC  for  Security,  WHO  for  Who  involve,  and  MEAS 
for    Measures. 


aihe  external  view  is  information  as  oresented  on  output 
reports,  displays,  etc..  and  its  correspondence  to  data  on 
input  sources.  It  is  this  correspondence  between  the  data 
and  the  information  derived  upon  which  the  user's  external 
view    is    based.    [ Ref .     14] 
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Table    2.    Applications    to   Data    Elements    Groups    Mapping 


No.    Applications 


Data    Elements  Groups 
MAINID  PERSCHAR 

MARR    ADDR    BODYCHAR    CATEG 


1.  Personal    identifi- 
cation   and   the   com- 
fcir.aticn   of   all 
applications 

2.  Personal   Charac- 
teristic 

3.  Bank    promotion   and 
regular   reports 


4. 

Profession 

5. 

Education 

6. 

Family 

7. 

Fayroll 

8. 

Security 

X                        X 

X 

X 

X 

X                       X 

X 

X 

X 

X 

X 

X 

X 

X 

X                       X 

X 

X                       X 

X 

X 

X 

So.     Applications 


Data    Elements  Groups 
RANK  PROFF  EDDC    +    SUBJ 


Personal    identifi- 
cation   and   the   com- 
bination   of    all 


applications                  : 

2. 

Personal    Charac- 
teristic                         : 

3. 

Sank    Dromotion   and 
regular   reports          : 

4. 

Profession                      : 

5. 

Education                        : 

6. 

Family                               : 

7. 

Fayroll                             : 

8. 

Security                           : 

X 
X 
X 

X 
X 


X 
X 

X 

X 

X 
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Table   2.     (continued) 


No.    Applications 


Data    Elements  Groups 

PAH    ♦  PAYROLL  SEC 

(FACT    S    FEDUC)  (WHO    Z    MEAS) 


1.  Fersonal    identifi- 
cation   and   the   com- 
bination   of    all 
applications 

2.  Fersonal   Charac- 
teristic 

3.  Sank    Dromotion   and 
regular   reports 

4.  Profession 

5.  Education 

6.  Family 

7.  Payroll 

8.  Security 


X 


X 


X 

X 


X 
X 
X 


Considering  the  external  view  and  special  processing 
reguirements,  now  the  author  can  determine  the  reguired 
local  view9  for  each  application  function,  as  depicted  in 
Diagram  2.  Note;  circled  numbers  1  through  8  represent  the 
application  numbers  depicted  in  Table  2.  The  relation 
attribute    shewn    in    Diagram    2    is    named    "need." 


9The  local  view  reoresents  that  portion  of  the  Data  Base 
reguired  to  supcort  a  particular  amplication  function  to 
aenerate  the  external  view  or,  in  the  case  of  update,  to 
absorb  the  external  view.  The  collection  of  local  views  for 
the  various  anolications  functions  using  the  Data  Base  det- 
ermines   the    requirements   of  the    external   view.    [Ref.     14] 
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MAIN  ID 


PEBSCHAB 


—    MAR  P. 


r—    ADDR 


BODYCHAR 


*—    CAT  EG 


RANK 


PROFESS 


2DUC 


^ 


SU3J 


FAM 


r-    FACT 


»—    FEDUC 


PAYROLL 


SEC 


— i     WHO 


MEAS 


Diagram    2.    Local    view   for  each   application 
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C.     DATA    MODEL    DESIGN 

Hew  is  the  time  to  derive  the  required  content  and  struc- 
ture of  the  internal  viewl°  which  is  the  end  result  of  the 
data  model  design.  The  primary  tool  in  Data  Base  design  is 
a  good  data  model  design  which  satisfies  the  organization's 
requirements   and   specifies   the  conceptual    design. 

Seme  characterization  of  a  "good"  conceptual  design  as 
extracted  from  Diane  C.  P.  and  J.  M.  Smith  paper  [Hef.  16] 
are    as   follows: 

Ccncept    complete:    derivable  concepts   should   be   included. 

This  concept  guarantees  that  no  useful  objects  are  left 
cut  of  the  Data  Base  and  that  designers  are  not  inappro- 
priately constrained.  For  many  derived  concepts  the  der- 
ivation can  only  be  made  in  one  direction,  but  when  the 
derivation  is  reversible  there  may  be  a  performance  rea- 
son for  choosing  one  object  to  be  the  base  and  the  other 
tc    be    derived. 

Evolvable:  it  should  be  locally  modifiable  and  it  should 
be   flexible   in   supporting   user   interpretations. 

Locally  modifiable  in  each  iterations  produced  by  the 
design  process  will  make  the  process  becomes  easy  and 
time   saving.  Flexibility   of   interpretation      is   another 

property  that  facilitates  the  design  process  in  that  new 
applications  may  be  added  with  potentially  little  impact 
on   the    existing   design. 

Independence        of        existing  installation        and        DBMS 

constraints. 


lo^he  internal  view  is  the  complete  data  structure  main- 
tained by  the  system  to  generate  the  multiple  local  views. 
The    internal    view   describes  the    Data    Base    itself.    [Ref.    14] 
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Develop  the  design  independent  of  current  state 
limitations  and  conventions  first  and  then  tailor  it  to 
the  system.  When  changes  occur  the  original  design  will 
be  available  to  facilitate  system  update  or  conversion. 

From  the  local  view  as  depicted  in  Diagram  2,  the  author 
can  derive  the  relationship  between  the  data  element  groups 
as  tc  the  cwner  and  the  member11  as  depicted  in  Table  3.  The 
relationship  "is-part-of"  is  the  attribute  name  of  the  rela- 
tionship from  the  member  to  the  owner,  or  attribute  name 
"has-      "12  from  the  cwner  to  the  member. 

Regarding  the  data  model,  further  Diane  C.  P.  and  J.  M. 
Smith  [Ref.  16]  define  each  of  the  following  properties  con- 
tribute to  the  value  of  a  "good"  data  model: 

It  should  be  expressive. 

A  data  model  should  be  sensitive  to  important  distinc- 
tions, so  it  will  guide  its  users  to  include  the  concepts 
and  objects  necessary  to  a  good  design. 

It  should  not  over-constrain  implementors. 

The  lata  model  should  not  imply  a  particular  implementa- 
tion strategies  and  its  vocabulary  should  be  at  a  high 
enough  level  to  be  free  of  implementation  connotations. 

A  data  model  should  have  a  formal  basis. 

This  provides  the  physical  designers  and  implementors 
with  a  sound  foundation  for  verifying  their  work  and  eli- 
minates the  ambiguity. 


iiThe  cwner  is  the  same  as  master, superior  or  parent 
arouc  which  has  zero  or  more  Member  (subordinate  or  depen- 
dent) grouo  of  data  elements. 


i2Where     "-oersonai     characteristic," 
"-profession, "  etc,  are  substituted  for  "-       " 

3a 


"-rank," 


Table    3.    Data    elements    groups    (as    owner-member) 
relationship 


Owner 


Member 

MAINID    PERSCHAR    RANK    PROPF    EDOC    FAU    PAYROLL    SEC 
abed  efg  hi 

MAINID  X  X  X  X  X  X  X 

PEBSCHAB 


X    X    X    X 


RANK 

PFOFP 

EDOC 

FAM 

PAYROLL 
SEC 


X    X 


X    X 


Bete:    a  =   marr,   b  =  adde,   c  =   bodychar,    d  =  categ,    e  =   subj, 

f    =    FACT,    g    =    FSDOC,    h    =    WHO,    i   =    SEAS. 


A    data    model    should    be    widely    applicable. 

Tc  produce  an  integrated  design  that  can  be  checked  for 
internal  consistency,  we  have  to  use  one  data  model  which 
encompass  applications  that  are  very  dynamic,  very  scien- 
tific,   and   very   commercial    in    their   orientation. 
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A    data    model    should   be   understandable. 

k  data  Model  should  provide  some  kind  of  non-technical 
presentation,  pictorial,  and  utilising  the  terminology 
and  linguistic   constructs   of    the   end   user. 

Finally  and  most  fundamentally,  a  data  model  must  reflect 
and  support   human   concept   formation   and    understanding. 

The  composition  rules  (syntax)  of  the  data  model  do  not 
fcrce  its  users  to  assemble  objects  in  ways  that  differ 
from  how  they  would  naturally  assemble  them,  because 
humans    have    innate    mechanisms    for   coping    with    complexity. 

The  utility  of  a  data  model  depends  not  just  on  the  prop- 
erties described  above,  but  also  en  the  existance  of  a  set 
of  rules  or  a  methodology  for  using  it.  Without  such  gui- 
dance many  designs  may  be  produced  even  using  a  good  data 
model   before    an   acceptable   one   is  achieved. 

The  method  for  modelling  the  individual  structured  compo- 
nents pertinent  to  an  enterprise  and  their  interrelation- 
ships is  based  on  mechanisms  that  human  use  for  thinking 
about  such  things.  It  is  the  premise  of  this  data  model  that 
we  as  human  beings  succeed  in  understanding  complex  systems 
by  creating  abstractions  from  that  can  be  named  and  con- 
ceived of  as  a  whole.  Thus,  an  abstraction  of  a  system  is  a 
collection   of   details   that    can  be   treated   as   a    whole. 

Finally  from  all  of  the  above  analysis  author  can  derive 
a    data  model    as    depicted   in   Diagram   3. 

The  data  elements  which  are  in  the  groups  can  be  seen  in 
chapter   2    section    D    (Data    Elements   and   Their    Groupings). 

The  key  of  each  group  is:  personal  serial  number  for 
Main    Identification      group    (this      also   as      the    main      key    for 
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a  apr 


id:)r 


EOCYCHAR 


MEAS 


Diagram  3.  Personnel  Data  Model 


each  person),  marital  status  for  Marriage  subgroup,  housing 
status  for  Address  subgroup,  blood  type  for  3ody 
Characteristic  subgroup,  current  personal  status  for 
Category  and  Status  subgroup,  rank  for  Rank  group,  echelon 
of  profession  for  Profession  group,  group  code  of  education 
for  Education  group,  subject  for  Subjects  subgroup,  family 
relation  for  family  group,  name  of  activity  for  Activity 
subgroup,  family  group  code  of  education  for  Family 
Education  subgroup,  unit  of  payroll  for  the  Payroll  group, 
violation/infringe  type  for  Security  group,  name  involved 
for  Who  involved  subgroup,  and  action  type  for  Measures 
subgroup . 

Per  the  complete  description  see  the  Data  Base  dictionary 
in  Appendix  E. 
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D.  SPECIAL  DISCUSSIONS 

1 .  Personal  Serial  Number 

The  personal  serial  number  is  the  main  key  in  the 
Personnel  Data  3ase.  Many  significant  differences  exist 
between  military  and  civilian  serial  numbers.  Even  within 
the  military  there  are  a  large  number  of  major  differences. 
In  order  to  make  accessing  the  Data  Base  easier,  the  per- 
sonal serial  number  must  be  transformed  into  a  common  form 
before  they  are  actually  stored  in  the  Data  Base.  Thus,  a 
routine  must  be  designed  to  transform  the  various  forms  of 
personal  serial  numbers  into  a  common  form  before  storing 
them  in  the  Data  3ase  and  then  transform  them  back  to  their 
original  form  upon  retrieval. 

Eelow  are  the  recommended   transformations  for  personal 
serial  numbers: 

a.  Military: 

1) .  Officer: 

a)  .    Regular:    OOHNNMNNN 

Example:  3999/P  ====>  000008999 

b)  .  Titular:  10NNNHHWN 

Example:  7133/PT  — ===>  100007188 

c)  .  Military  obligated:  20YYNNNNN 

Example:  7919786/W  =====>  207919786 

2).  Warrant  Officer  and  below: 

a).  Regular:  30NNNNNNN 

Example:  93246  ==  =  =>  300093246 

b)  .  Military  obliged:  40YYNNNNN 

Example:  8025134  =====>  '408025134 
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b.     Civilian:    5NNNNNNNN 

Example:    30599791    =====>    530599791 

2  •    Security  Group 

This  group  is  provided  as  an  additional  one  because  of 
its  importance  to  users.  There  is  no  data  available  for  it 
at  the  present  in  Dispullahtal,  but  it  is  maintained  in  the 
Intelligence-Security   Office. 

This  group  can  only  be  accessed  by  authorized 
Intelligence-Security  Personnel,  and  thus  it  must  be  given 
special  treatment.  Only  those  who  are  priviledged  to  use  it 
can  access  these  groups/segments.  Thus,  data  security13  is 
reguired  for  this  group.  The  issue  of  security  enforcement 
involves  two  things:  (1)  authorization  procedures  which  not 
only  help  in  user  identification  but  allow  users  to  deter- 
mine their  own  passwords,  and  (2)  control  by  the  system  of 
user    actions     after   authorization   is    given.  Security   con- 

trols range  from  simple  sign-on  procedures  that  access  to 
the  whole  system,  through  passwords  that  control  access  to 
different  levels  of  the  Data  3ase,  to  elaborate  access 
matrices  and  programmed  procedures-  Furthermore,  coopera- 
tion between  the  Intelligence-Security  officer  and  the  DBA 
is  a  must  in  controlling  and  maintaining  the  security  data 
element   grcup. 

3.    Data    Diet  ionary/Directorie  s    (DD^D) 

Individual  DBMS'  have  their  own  methods  to  predefine 
data    descriptions.      Each    has   a      repository    for   the    Data    3ase 


13Data   security   is    protection   of      the   data   against    unau- 
thorized   disclosure,    alteration,    or   destruction.  "[ Ref .     17] 
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description,  a        language      facility        to        process        that 

description,      and   a      mechanism  tc   input  that      description    to 
the    EBMS. 

The    general   objectives   of    a   DD/D  [Ref.     19]   are   to: 

Prevent  unplanned  redundancy  and  inconsistency  in  appli- 
cation systems  development  in  the  areas  of  source-data 
collection,  processing,  secondary  storage,  and  informa- 
tion  to   users. 

Reduce  application  systems  development  and  implementation 
lead   times  and   costs. 

Reduce    applications    modification   lead    times    and   costs. 

Allow  for  establishment  and  enforcement  of  standards 
relating  tc  data  usage  and  responsibility  (format,  mean- 
ing,   validity,    timeliness,    and    so    forth). 

In  most  DBHS's  the  included  data  dictionary  is  primar- 
ily oriented  toward  the  internal  representation  or  the 
machine  use  of  the  data  definition.  It  defines  the  internal 
form,  physical  location,  and  access  to  the  stored  data.  Clay 
R.  Sprowis  [Ref.  17]  says  that  the  data  dictionary  is  pri- 
marily 

a  directory  that  defines  the  internally  necessary 
attributes  of  the  data,  their  physical  character- 
istics,   and   stored    locations. 

The  Data  Base  description  does  contain  some  dictionary 
information  oriented  toward  the  user.  But  it  does  not  pro- 
vide all  of  the  information  that  a  good  dictionary  should 
provide  for  the  variety  of  users  who  need  access  to  data 
descriptions.  Clay  R.  Sprowis  [Ref.  17]  lists  some  sug- 
gested contents    of   data    dictionary  as    follows 

Osage:  status  (tentative  or  approved) ,  effective  data, 
programs    (used   by) ,    and    users     (both   formal    and   informal) . 
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Relationships:  field  (group,  record,  file,  set,  network), 
linkage  (pointers  to  and  from) ,  parent  of,  child  of, 
sorted  order  by  key,  and  relative  position  in  data 
description. 

Administrative  control:  ownership  (department,  department 
position),  definition  (proposed  by,  analyst  name), 
authority  to  access  data  (to  define,  to  add  or  delete,  to 
change)  ,  security  (special  provisions) ,  source  (input, 
document  description,  generated,  and  algorithm  to 
ccmpu  te« 

Identification:  label,  programming  language  name,  syno- 
nyms (if  same  data  field  is  used  more  than  once),  textual 
descriptions  (including  perhaps  keyword  descriptions), 
version  number  (for  validation  changes),  lost  change  date 
(for  keeping  data  definitions  current)  . 

Technical  specifications:  data  type  (quantitative  or  qua- 
litative), use  (external  and  internal),  form  of  each  use 
(length,  representation  or  picture,  precision,  mode, 
justification,  report  form  edited) ,  unit  of  measure,  time 
dependency  (for  update),  accessing  (record  key  or  index), 
data  validation,  edit  masks  (valid  codes),  value  range, 
and  test  data  (for  program  listing). 

An  exact  list  of  dictionary  contents  for  an  organiza- 
tion and  its  DBMS  depends  upon  the  breadth  and  emphasis  it 
places  on  the  use  of  the  dictionary.  The  data  dictionary 
for  the  Personnel  Data  3ase  and  its  description  are  depicted 
in  Appendix  B. 

4  .  Journalizing 

A  Data  Base  Management  System  must  provide  a  means  to 
restore  the   Data  Base  to   a  consistent  state  that  reflects 
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the  situation  after  some  number  of  transactions  were  com- 
pleted. The  journal  is  a  basic  accounting  record  in  which 
all  transactions  of  a  certain  type  are  recorded.  A  system 
journal  records  every  transaction  that  occurs  within  the 
system.  Jeffrey  D.  Ullman  [Ref.  20]  lists  the  most  general 
case  of  journal  entries  which  consists  of  (1)  a  unique  iden- 
tifier for  any  transaction  causing  a  change,  (2)  the  old 
value  of  the  item,  and  (3)  the  new  value  of  the  item. 

In  this  Data  Base  the  author  suggests  that  journal 
entries  consist  of: 

Identification  of  the  users  accessing  the  Data  Base. 

Type  of  operation  accessing  the  Data  Base  (update, 
insert,  delete,  list,  etc.). 

Fcinter  to  the  record  being  accessed. 

Personal  serial  number  of  the  record  being  accessed. 

The  old  value  of  the  item. 

The  new  value  of  the  item. 

Time  and  date  of  the  beginning  and  of  the  end  of  transac- 
tions and  accesses. 

Summaries  which  contain  the  number  of  personnel  in  the 
Navy  either  military  or  civilian,  number  of  personnel  in 
each  rank. 

5 .  Administration 

The  Data  Base  administration  is  the  agency  which  exer- 
cises centralized  control  over  the  Data  Base  System.  It 
includes  several  specialties,  including  information  system 
analysis,  data  structure  and  data  storage  organization 
design,  security,  recovery,  auditing,   and  accounting.   Each 
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of  these  specialties  may  be  assigned  to  one  individual  for 
an  uncomplicated  Data  Base  used  under  undemanding 
conditions . 

The  individual  in  charge  of  the  Data  Base  administra- 
tion is  the  Data  Base  Administrator  (DBA).  The  DBA  uses  the 
computer  to  build  and  operate  his  tools.  Such  tools  may 
include  system  flow  analysis  tools,  data  relationship  analy- 
sis tools,  performance  simulators,  data  storage  organization 
and  reorganization  tools,  and  other  utilities.  Beside  the 
DBA  the  personnel  with  the  specialties  mentioned  above  must 
be  organized  to  manage  and  improve  the  Data  Base. 
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IV.     CONCLUSIONS    &nd    RECOMMENDATIONS 

This  thesis  project  explored  the  step-by-step  logical 
design  of   the   Personnel   Data   Base   model   which   covers: 

1.  Gathering,  recording,  and  analyzing  the  user  require- 
ments, including  the  analysis  of  the  applications 
function  and  determining  data  element  groupings.  This 
Data  Base  consists  cf  97  (ninety  seven)  data  elements 
which  have  been  divided  into  17  (seventeen)  data  ele- 
ment  groups. 

2.  Deriving  and  designing  a  logical  data  model,  includ- 
ing the  analysis  of  data  element  groups  relation- 
ships, applications  to  data  element  groups  relation- 
ships, and  determining  the  Personnel  Data  Base  model. 
The  structure  of  the  data  model  designed  is  hierarch- 
ical. The  Data  Base  dictionary  was  also  designed  as 
a  directory  for  the  Data  Base  and  is  included  in 
Appendix    B. 

The  Data  Base  design  effort  is  not  completed,  and  can  not 
be,  until  the  logical  design  is  finished.  After  this  has 
been  done  the  logical  design  must  be  transformed  to  a  physi- 
cal   design.      The  author's    recommendations   are: 

1.  To  continue  and  to  complete  the  design.  This  involves 
applying    this   data    model    to  a    physical    machine. 

2.  To  form  and  organize  a  Data  Base  administration, 
identifying  the  personnel  needed  to  manage  and 
improve    the   Data   Base. 
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APPENDIX    A 


LIST    OF    DATA    ELEMENTS    FROM    FILE    SYSTEM 

1.  Personal    Serial   Number 

2.  Check   Digit   of   the    Personal  Serial   Number 

3.  Duplication   Cede    of   the  Personal   Serial   Number 

4.  Batch    Number 

5-  Name's   Spelling   Code    (Old    or  New) 

6 .,  I  a  m  e 

7.  Original    based   name    from 

8.  Corps 

9.  Named   based  originally   from 

10.  Current   Personal   Status 

11.  Date   of  Current   Personal    Status 

12.  Personal    Category 

12.  Da-e   of   Personal   Category 

14.  Date   of    3irrh 

15.  Current    station 

16.  Current   Rank 

17.  Active      Du-cy      Obligation    Time       (Active      Duty      Service 
Began) 

18.  Sex 

19.  Marital  Status 

20.  Number  of  wives 

21.  dumber  of  Children 

22.  Number  of  Children  Authorized  Family  Allowance 

23.  Status  of  Children  Authorized  Family  Allowance 

24.  Status  of  House 

25.  31ccd  Type 
2  6.  Weight 
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27.  Height 

28.  Color   of    Skin 

29.  Hair 

30.  Color    of    Eyes 

31.  Size   of   Shoes 

32.  Size    of   Hat 

33.  Size   of   Pants 

34.  Size   of   Shirt 

35.  Size   of   Chest 

36.  Unit    of   Administration 

37.  Unit   of    Payroll 

38.  Unit   of   Individual's  Field    Provisions    (Equipment) 

39.  Unit   of   Side   Dishes    Money 

40.  Religion 
4  1.  Tribe 

42.  Place   of   Birth 

43.  Rank 

44.  Status   of   Rank 
4  5.  Date   of    Rank 

46.  Decision    Letter    of    Rank 

47.  Date   of   Decision    Letter   of   Rank 

4  8.  Who   Gave    the   Decision   Letter 

49.  Type   of    Promotion 

50.  Date    of   Profession 

5  1.  Status  of   Placement 

52.  Date   of   Placement 

53.  Station 

54.  Reporting   Date 

55.  Profession's    Name 

56.  Rank    in   Profession 

57.  Decision    Letter    of    Profession 

58.  Date   of  Profession's  Decision   Letter 

59.  Warrant   of   Profession 

60.  Date  of   Warrant   of    Profession 
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6  1.  Echelon    (Group)     of    Profession 

62.  Group   Code   of   Education 

63.  Start   Date   of   Education 

64.  Completion   Date   of   Education 

65.  Place   of   Education    (Station,    Town) 

66.  Educational   Institute's   Name 

67.  Result   of   the    Education 

6  8.  Class    Standing 

69.  Class    Size 

70.  Relative's   Identity 

7  1.  Relative's   Name 

72.  Relative's   Relation 

73.  Relative's   Birth    Date 
7U.  Relative's    Sex 

75.  Relative's   Birth    Place 

76.  Relative's   Religion 

77.  Code   of   the   Relative's  Description 

78.  Relative's   Description 

79.  Date  of   Payroll 

8  0.  Rank    in   Payroll 

8  1-  Status  of    Payroll   Period 

82.  Payroll   Period 

83.  Marital   Status   in   Payroll 
8U.  Main    Salary 

85.  Wife's   Family    Allowance 

36.  Other   Family   Allowance 

87.  Children    Family    Allowance 

38.  Extra    Earnings 

39.  Main   Seduction   of   Salary 

9  0.  Rice   Reductions 

9  1.  Advance   Payment    Reductions 

92.  Housing  Reductions 

93.  Loss-damage    Reductions 
9U.  Other    Reductions 


til 


95.  Reduction's   Code 

96.  Completion      Date    for      the      Reduction      of    the      Advance 
Payment 

97.  Completion    Date    for   the   Reduction   of    Loss-damage 

98.  Completion   Date    for   Other's  Reduction 

99.  Salary   Round-off 
1C0.    Unit    of    Payroll 


U8 


APPENDIX    B 

DAT.A    BASS    DICTIONARY 

This  data  dictionary  contains  descriptions  of  the 
Personnel  Data  Base  segments  (data  elements  groups)  and 
their   data    elements.      There  are    six  columns    in    the  table: 

1.  Element  Number  (ELS  #)  .  The  data  element/segment 
number  contains  four  digits.  The  first  two  digits  is 
the  segment  number,  baginning  from  the  root  and 
increasing  by  one  (leading  zeroes  suppressed),  and 
another  two  digits  for  the  data  element  number  in  the 
segment    beginning   from   one   and   increasing   by  one. 

For   example:         1005    indicates      the    tenth      segment    and 
data   element   number   five    in   the   segment. 

2.  Data  Element  (DATA-ELESE NT) «  This  column  contains 
data  element/segment  name  as  it  is  known  to  the 
users. 

3.  Data  Name  (DATA-NAME).  This  column  contains  the  uni- 
que name  for  data  element/segment  which  is  to  be  used 
by  programmer/user  when  retrieving  data  from  the  Data 
3  ase. 

4.  Type  (TYPE).  This  column  contains  the  data  element's 
type  where  N  means  Numeric  and  AN  means  Alpha 
Numeric. 

5.  Number  of  Character  (#  OP  CHAR).  This  column  con- 
tains number  of  characters  in  the  record  field  of  the 
data    element/segment. 
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6.  Description  (DESCRIPTION)  .  This  column  contains  the 
description  of  the  data  element/segment.  Described 
are  the  data  element/segment  relationships  (depen- 
dent, root,  etc.),  key  record/segment,  administrative 
control,  usage,  and  identifications.  This  description 
helps  the  programmer/user  to  find  the  path  to  desired 
data   element/segment   in   the  Data   Base. 

The  abbreviations  used  in  the  data  dictionary 
table  are:  D3  for  Data  Base,  segm  for  segment,  lev 
for  level,  tbl  for  table  and  refer  to  the  Personal 
Tables  (numbered  in  parenthesis)  in  APPENDIX  C. 
YYMMDD  for  Year  (two  digits)  Month  (two  digits)  and 
Date  (two  digits) ,  cccurr  for  occurrence,  dependt  for 
dependent.    Kg   for   Kilogram,    and   Cm    for  Centimeter. 


ELH  DATA-  DATA-  TY-       #    OF    DESCRIPTION 

#  ELEMENT  NAME  PE         CHAR 


100    Main    identification      MAINID  76         Root   segm    DB 

lev    1,    segm    1, 


one   occurr 


101  Personal   Serial 
Num  ber 

102  Name 

103  Corps 

104  Sex 

105  Birth   date 

106  Birth    place 

107  Religion 


108    Tribe  TFI3E  AN         15 
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SERNUM 

N 

9 

Record  key 
(Main   key) 

NAME 

AN 

26 

Name,    title 

CORPS 

N 

3 

See   corps    tbl 
(19) 

SEX 

N 

1 

See    sex   tbl    (3) 

DM3IRTH 

N 

6 

YYMMDD 

PMBIRT  H 

AN 

15 

Town    (city) 

RELIGION 

N 

1 

See   religion 
tbl    (12) 

200  Personal 

characteristics 


CHARACT 


Dependt  segm  of 
root,  lev  1, 
segm  2,  one 
occurr 


300  Marriage 


30  1  Harital  status 


3  02  Date  cf  status 


HARR 


3ARST 


MARDT 


Dependt  segm  of 
CHARACT,  lev  3, 
segm  3, 

repeated 

See  marital 
status  tbl  (U) , 
segm  key 
YYHHDD 


400  Address 


401  Address 

U02  Housing  status 


U03  Date  of  status 


ADDR 

33 

Dependt  segm  of 
CHARACT,  lev  3, 
segm  4, 
repeated 

ADDRESS 

AN 

26 

- 

HOOSE 

N 

1 

See  housing 

HOOSSDT      N 


status   tbl    (6) , 
segm    key 

YYBMDD 


500    3cd7    characteristic      EODYCHAR 


50  1    Weight 
502    Height 


EODYCHAR 

18 

Dependt  segm  of 
CHARACT,  lev  3, 
segm  5,  one 
occurr 

WEIGHT    N 

3 

In  Kg 

HEIGHT    N 

3 

In  Cm 
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503  Blood    type 

504  Color   of   skin 

505  Hair 

506  Color  of  eyes 

507  Size  of  shoes 

508  Size  of  hat 

509  Size  of  pants 

510  Size  of  shirt 

511  Size  cf  chest 


BLOOD     N 


SKIN 


HAIR 


EYES 


1    See  blood  type 
tbl  (7)  ,  segm 
key 

1    See  color  of 
skin  tbl  (8) 

1    See  hair  tbl 

(9) 

1    See  color  of 
eyes  tbl  (10) 


SHOES 

N 

2 

- 

HAT 

N 

2 

- 

PANTS 

N 

1 

See 

tbl 

pant  shirt 
(11) 

SHIRT 

N 

1 

See 
tbl 

pant  shirt 
(11) 

CHEST     N 


600  Category  and  status   CATEG 


601  Original  personal 
status 

602  Date  cf  original 
personal  status 

603  Current  personal 
status 

604  Date  of  current 
personal  status 

605  Personal  category 


ORPSRST   N 


CRPERDT   N 


CRPERST   N 


CRPERDT   N 


CATEGORY  N 


29    Dependt  segm  of 
CHARACT,  lev  3, 
segm  6,  one 
occurr 

2    See  personal 

status  tbl  (1) 
5    YYMMDD 

2    See  personal 

status  tbl  (1) , 
segm  key 

5    YYMMDD 

1  See  personal 
category  tbl 
(2) 
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606  Date    cf   personal 
category 

607  Active    duty   obliga-       DTACT 
ted    time    (Active 
service    duty   began) 


DTGORI         N 


YYMMDD 


6  YYMMDD 


70  0    Rank 


RANK 


39 


70  1    Rank/Group 


702    Status   of   rank 


RANKG  N 


STRANK         N 


703  Date    of    rank  DTRANK        N  6 

704  Number   of    decision         N3DECLET   AN  3 
letter 


705  Date    of    decision  DTDECLST   N  5 
letter 

706  Who    gave   the    decisi-    GVDECLET   AN         15 
on    letter 

707  Type    cf    promotion  TPPROM        N  1 


Dependt   segra    of 
root,    lev    2, segm 
3,    repeated 

See   rank   tbl 
(18)  ,    segm   key 
See   status   of 
rank  tbl     (13) 
YYMMDD 

Format:NNNNMMYY 
NNNN:    number 
MM      :    month 
YY      :    year 
YYMMDD 

Official 
functionary 
See   type    of 
promotion    tbl 
(14) 


900    Profession 


PROFESS 
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901    Name    cf    profession         NMPROF         AN         15 


Dependt    segm    of 
root,    lev    2, 
segm    4, 

repeated 
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832    Number   of   decision        NBDEC?        AN  8 

letter 


803  Date   of    decision  DTPROF        N 
letter 

804  Number   cf   professi-      NBWARP        AN 
onal    warrant 


805  Date    cf    warrant 

806  Echelcn    of 
pro  f essicn 

307    Station 


DTWAR?         N 
ECHELON      N 

STATION      N 


8  08    Reporting   date  DTSTAT        N 

309    Status   of    placement       STPLAC E      N 


310    Date    of    clacement  DTPLACE      N 


Format:NNNNMMYY 
NNNNrNuraber 
MM:Month 
YY:Year 
NNNNNN-YYMMDD 


8 

Format:NNNNMMYY 

NNNN:Number 

MM: Month 

YY: Year 

5 

NNNNNN-YYMMDD 

2 

See  echelon 

tbl  (21) 

3 

See  station  tbl 

(22) 

6 

YYMMDD 

1 

See  status  of 

placement  tbl 

(15) 

6 

YYMMDD 

900    Education 


90  1    Group    cede    of 
education 


EDUC 


EDUCCD         N 
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90  2    Educational   Insti-  EDUCNM  AN  15 
tute's    Name 

903  Start    date  EDOCSD  N  6 

904  Completion    date  EDUCCM  N  6 


Dependt    segm   of 
root,    lev    2, 
segm    9, 

repeated 

See  group  code 
of  education 
tbl  (20)  ,  segm 
key 


YYMMDD 
YYMMDD 
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905  Station 


EDSTAT    N 


906  Town  (city)  EOT OWN    AN    15 

907  Result  of  education   RESULT    N     1 


908  Class  standing 

909  Class  size 


CSTAND    N      3 
CSIZE     N      3 


See  station 
tbl  (22) 

See  result  of 
education  tbl 
(16) 


1000  Subjects 


1001  Subject  name 

1002  Grade 


SOBJ 


18 


SUBJECT   AN    15 
GRADE     AN     3 


Dependt  segm  of 
EDUC,  lev  3, 
segm  10, 
repeated 

Segm  key 

Can   be  numeric 

or    alphabet 


1100    Family 


1101  Family  name 

1102  Faaiiv  relation 


1103  Sex 

110U  Birth   date 

1105  Birth  place 

1106  Religion 

1107  Address 


FAM 


76    Dependt  segm  of 
root,  lev  2, 
segm  6, 

repeated 


FN  A  MS 

AN 

26 

Name,  title 

FREL 

N 

1 

See  family 
relation  tbl 
(17) ,  segm  key 

FSEX 

N 

1 

See  sex  tbl 
(3) 

FDBIRTH 

N 

0 

YYMMDD 

FPBIRTH 

AN 

15 

Town  (city) 

FRELIGI 

N 

1 

See  religion 
tbl  (12) 

FADDR 


AN 


26 
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1200    Activity 


120  1  Name    cf    activity 

1202  Place   of   activity 

1203  Start    date 

1204  Completion    date 


FACT 

48 

Dependt  segm  of 
FAM,  lev  3, 
segm  12, 
repeated 

FNACT 

AN 

26 

Segm  key 

FPACT 

AN 

15 

Town  (city) 

FSACT 

N 

6 

YYMMDD 

FCACT 

N 

5 

YYMMDD 

1300  Family    education  FEDUC  16         Dependt    segm    of 

FAM,  lev  3, 
segm  13, 
repeated 

1301  Educational  Insti-    FEDNACT   AN    15 
tut e' s  Name 

1302  Group  code  of        FCDACT     N     3    See  group  code 
education  of  education 

tbl  (20) ,  segm 
key 

1303  Result  of  education   FEDRES     N     1    See  result  of 

education  tbl 
(16) 

1400  Payroll  PAYROLL       59    Dependt  segm  cf 

root,  lev  2, 
segm  14,  one 
occurr 

1401  Date    of    beginning  D3PAY  N  6         YYMMDD 
payroll 

1402  Rank    in    payroll  RKPAY  H  2         See   rank    tbl 

(18) 

1403  Payroll    period  PERPAY         N  3         In    month 
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1404  Number   cf    children        CHFA.1  N  1 
authorized    family 

allowance 

1405  Status   of   children        STCHFAM     N  1         See   children 
authorized    family  allowance    sta- 
allowance  tus   tbl    (5) 

1406  Bain    salary  MAINSAL     N 

1407  Wife's    Family  WFALL  N 
Allowance 

140  3    Children   Family  CHALL  N 

Allowance 

1409  Other    family   alio-         OTALL  N 
Allowances 

1410  Obligated  reductions   OBRED  N 

1411  Rice    reductions  RCRED  N 
14  12    Other    reductions             CTRED  N 

1413  Total    salary  TOTSAL        N 

1414  Onit    of    payroll  UNPAY  N 


6 

In 

Rupiah 

5 

In 

Rupiah 

5 

In 

Rupiah 

5 

In 

Rupiah 

5 

In 

Rupiah 

5 

In 

Rupiah 

5 

In 

Rupiah 

5 

In 

Rupiah 

4 

See  station  tbl 

(22)  ,  segm  key 

1500    Security  SEC  35         Dependt    segm    of 

root,    lev    2, 
segm    15, 
repeated 

150  1    Violation   /  Infringe    VTYPE  N  1         See    violation   / 

type  infringe    type 

tbl    (23)  ,    segm 
key 

1502  What  WHAT  N  3         See    what    tbl 

(24) 

1503  Where  WHERE     AN    15    Town  (city) 

1504  When  WHEN      N      5    YYMMDD 
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15  0  5  Why 


1506  How 


WHY 


HOW 


N 


This  reason 
description  is 
stored  in  other 
file  with  key 
number  here 
(N  5) 
Same  as  1505 


1600  Who  involved 


16  0  1  Name  involved 
1602  Personal 

identification 


1603  Profession 


WHOINV 


INVNAME   AN 
PEHSID    AN 
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26 

9 


Dependt  segm  of 
SEC,  lev  3, 
segm  16, 
repeated 

Segm  key 
Personal  Serial 
number  or  other 
valid 
identification 


PRO FIN  V   AN 


15 


17  0  0  Measures 


170  1  Type  of  action 

1702  Start  date 

1703  Completion  date 


MEAS 


27 


NMEAS  AN  15 
SMEAS  N  6 
CMEAS     N      6 


Dependt  segm  of 
SEC,  lev  3, 
segm  17, 

repeated 

Segm  key 

YYMMDD 

IYMHDD 
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APPENDIX  C 


DATA  BASE  PERSONNEL,  TABLES 


Each  of  these  tables  contains  two  elements:  code  and 
description.  Example:  "1  Male"  indicates  code  number  1  is 
Male. 

1.  PERSONAL  STATOS: 


03  Titular 


A.  Military: 

01  Volunteer 

02  Obliged 

B«    Civilian: 


11  Daily_labourer 

12  Mcnthly_labourer 

13  Monthly_labourer   organic 

14  Temporary   Gover nment_of f icial 

15  Pre_Go vernment_of ficial 

16  Civilian__Government_off  icial 

17  civilian_Military_Titul ar  Governaent_off icial 


2.  PERSONAL    CATEGORY: 

0  Net    Clear 

1  Active  organic 

2  In  charge 

3  In  assistance 

4  in   direction 

3.  SEX: 

1    Male 


5  Waiting   for    placement 

6  Waiting   for    direction 

7  Pre_retired 

8  Money    waiting    (UT) 

9  Retired 


2   Female 
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4.  MARITAL    STATOS: 

1    Married  2   Not   married 

5.  CEILDREU    ALLOWANCE    STATOS: 

1    Claimed    by    him/herself      2   Claimed   by    spous* 

6.  HCOSING    STATUS: 

1  Government-quarters  4   Private/owned 

2  Mess  5   Rented 

3  Ship  6   Contract/Leased 
7    with   relations 

7.  BLOOD    TYPE: 

1  A  3    AB 

2  B  4    0 

8„     CCLOOR    OF    SKIH: 

1  White  4   Yellow-brown 

2  Yellow  5   Brown 

3  Black 

9-     HAIR: 

1  Straight-lank  3   Straight-stiff 

2  Curly  4   Weavy 

10.  COLOUR    OF    EYES: 

1  Black  3   Brown 

2  Blue  4   Sreen 

11.  SIZE    OF    PANTS/SHIRTS: 

1  Small  3   Large 

2  Medium 

12.  FELIGION: 

1    Moslem  <*   a indu 
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2  Catholic 

3  Protestant 

13.  STATUS    OF    RANK: 

1  Effective 

2  Temporary 

3  In    education 

14.  TYPE    OF    PROMOTION: 

1  Regular 

2  Extraordinary 

15.  STATUS  OF  PLACEMENT: 

0  Organic 

1  Labour  (non  organic) 

2  In  charge  (detached 
from  parent  command) 

16.  RESULT    OF    EDUCATION: 

1  Graduated 

2  Not    graduated 

17.  FAMILY    RELATION: 

0  Spouse 

1  Child    number  1 

2  Child   number  2 

3  Child    number  3 

4  Child    number  4 

18.  FANK: 

A.    Military: 

99    Third    Sailor 
93    Second   Sailor 
97    First    Sailor 
9  6    Second   Corporal 


5  3udha 

6  Kong   Hu  Cu 


4  Military  obliged 

5  Military   titular 


3  Honour    (meritorious) 

4  Honour-grace     (posthumous) 


3  In   assistance    (temporary 
additional    duty) 

4  In   direction    (independent 
d  ut  y) 


3   I ncomplete 


5  Child  number  5 

6  Child  number  6 

7  Child  number  7 
3  Child  number  8 
9  Child  number  9 
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95  First    Corporal 

88  Second   Sergeant 

87  First    Sergeant 

86  Head   Sergeant 

85  Sergeant   Major 

84  Second    Assistant    Lieutenant 

8  3  First    Assistant   Lieutenant 

82  Candidate   Officer 

7  8  Second   Lieutenant 

7  7  First    Lieutenant 

76  Captain 

6  8  Major 

6  7  Lieutenant   Colonel 

66  Colonel 

5  8  First    Admiral    (Commodore)    /   Brigadier   General 

57  Rear    Admiral   /   Major  General 

56  Vice   Admiral   /   Lieutenant  General 

55  Admiral   /  General 

E.   Civilian: 


4  8  Group  I/A 

47  Group  I/B 

4  6  Group  I/C 

4  5  Group  I/D 

3  8  Group  II/A 

3  7  Group  II/B 

3  6  Group  II/C 

3  5  Group  II/D 

28  Group  III/A 


21  Group  III/3 

26  Group  III/C 

25  Group  III/D 

18  Group  IV/A 

17  Group  IV/3 

16  Group  IV/C 

15  Group  I7/D 

14  Group  IV/E 


19.     CORPS: 


A.    Hilitarv: 


100   Sailor/Deck    (for  Officer  only) 

161  Deck 

162  Torpedo 
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1  63    Weapon 
16U  Constable 

165  Signal 

166  Telegrams 

167  Onder-water   Weaponry 

200  Technician/Engineer  (for  Officer  only) 

261  Machinist 

262  Construction 

263  Ship  Construction 

264  Airplane  Maintenance 

3  00  Electronics  (for  Officer  only) 

361  Radio 

362  Radio-Radar    Mechanic 

363  Electro-Machine    Mechanic 
36a    Electrician 

365    Sub-weapon   Electrician 

3  66    Electro    Mechanic 

367    Weapon    Electro    Mechanic 

3  68   Electro nica 

4  00    Harine    (for   Officer  only) 
4  6  1    Infantry 

462  Amphibious 

463  Field  Artillery 

464  Air  Defense  Artillery 

465  Tank 

466  Pansam    (Amphibious   Tank) 

467  Transportation 

468  Zipur    (Defense    Construction) 
4  69   Ccmmunication-Electronica 

470  Nurse 

471  Field  Support 

500    Administration    (for  Officer  only) 
56  1    Writer/Typist 
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562  Finance 

563  Support 

564  Family   business 

565  Ccck-1 

566  Cook 

567  Tailor 

6  00   Health    (for   Officer  only) 

661  Nurse 

662  Radiologist 

6  63    Analysist 

664  Dental   Technician 

665  Chemist 

666  Assistant    Chemist 

700   Specialist    (for   Officer  only) 

761  Judicature 

762  Intelligence 

763  Transportation 

764  Carpenter 

765  Physical  Fitness 

7  66  Musician 

767  Photography 

768  Cinematography 

769  Miscellaneous 

800    Woman    (for   Officer   only) 

861  Communication 

862  Writer/Typist 

863  Finance 

864  Information 

865  Physical  Fitness 

866  Nurse 

867  Nav-Inf ormation    Defense 

8  68   Air   Traffic  Controller 

900   Clergy    (for   Officer  only) 
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E-   Civilian: 

000  Administration 

001  General   Administration 

002  Finance   Administration 

003  Labour    Administration 

004  Support   Administration 

005  Nursing    Administration 

006  Technic   Administration 

007  Typist 

008  Stencil   Mechanic 

009  Nursing   Staff 

0  10  Statistic   Administration 

0  11  Law    Administration 

0  12  Library   Administration 

0  13  Transportation    administration 

0  1U  Housing   Administration 

0  15  Post    Administration 

0  16  Miscellaneous   Administration 

0  17  Technic 

0  18  Ship  Technician 

019  Engine/machine  Technician 

0  20  Electro  Technician 

0  21  Construction  Technician 

0  22  Carpenter 

023  Welding   Technician 

024  Telephone-telegraph   Technician 

025  Radio   Technician 
0  26  Mechanic/driver 

027  Labourer 

028  Photographer 

029  Film  Operator 

0  30  Metal   Technician 

031  Painter 

032  Weapon  Technician 
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033  Firs  Safety  Inspector 
0  34  Constructor 

035  General  Controller 

036  Shipyard  Worker 

037  Pump  Technician 

0  38  Railroad  Technician 

039  Meteorological  Technician 

0U0  Miscellaneous 

041  Nurse 

042  Dental  Nurse 

0  43  General  Nursing 

044  Midwife 

045  Pharmacy 

046  Physiotheraphy 

047  Radiology 

048  Pediatric    Nurse 

049  General    Medical 

050  Ophthalmologist 

051  Throat-nose-ear    Physician 

052  Neurologist 

053  Dermatologist 
0  54    Dietitian 

055  Miscellaneous 

056  Specialist 

057  Teacher/instructor 

058  Messenger 
0  59  Cook 

060  Gardener 

061  Shoemaker 

062  Tailor 

063  Barber 

064  Janitor 

065  Forester 
0  66  Sk  etc  her 
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067  Security 

068  Lifeguard 

069  Parking   Master 

070  Fire    Brigade 

071  Physical   Fitness 

072  Artist 
0  73  Clergy 
0  74  Laundry 

075  Ocean   Tide 

076  Petro-che mical    Technician 

077  Geography 

078  Miscellaneous 

20.     GROUP    CODS    OF    EDUCATION: 

000  General    development 

C01  National   defense 

002  Joint    command    5    staff    college 

003  Command    5   staff    college    level 

004  2nd  Officer   continuing  education   level 

005  1st   Officer   continuing   education   level 
011  NCO   continuing   education 

100  Formation 

101  Military    Academy    level 

102  Fundamental   Officer  Education    level 

103  Candidate   Officer    education    level 

111  Candidate    NCO    education    level 

112  Candidate   Corporal    education   level 

113  Candidate   Enlisted   Education    level 

200  Labour 

201  Labour  education  level 

300  General  education 

301  University  level 

302  Academy  level 

303  Senior  high  school  level 
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304  Jur.icr   high   school    level 

305  Elementary   school    level     (graduated) 

306  Elementary   school    level    (not    graduated) 

400  Specialist   Military  education 

401  Specialist 

402  Officer    specialist 

403  NCO   specialist 

404  Enlisted  specialist 

405  Civilian   specialist 

500   General   Course 
21.     ECHELON    OF    PROFESSION: 

11  Echelon  1-A  23  Echelon  2-C 

12  Echelon  1-B  24  Echelon  2-D 

13  Echelon  1 -C  25  Echelon  2-E 

14  Echelon  1-D  25  Echelon  2-F 

15  Echelon  1-E  31  Echelon  3- A 

16  Echelon  1-F  32  Echelon  3-3 

17  Echelon  1 -G  33  Echelon  3-C 

18  Echelon  1-H  34  Echelon  3-D 

21  Echelon    2-A  35    Echelon    3-E 

22  Echelon   2-3  40    Functional 

22-     STATION: 

Not   included   here   for   security   reasons. 

23.  VIOLATION    /    INFRINGE    TYPE: 

1  Discipline  3   Negative   data 

2  Law 

24.  HHAT: 

This  table  will  be  completed  later  by  Intelligence  / 
Security  officer,  since  the  author  does  not  have  experience 
and  data  for  this. 
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